This invention relates to fault detection and isolation systems in communication networks. More particularly, and not by way of limitation, the invention is directed to a Connection Fault Management (CFM) maintenance point and method for providing Data Driven Connection Fault Management (DDCFM) in CFM maintenance points in a communication network.
Data Dependent and Data Driven Connection Fault Management (DDCFM) is described in the IEEE 802.1Qaw/D0.2 document, “Draft Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks—Amendment 10: Data Driven and Data Dependent Connectivity Fault Management,” April 2007, DDCFM provides operators with capabilities for detecting and isolating data-dependent and data-driven faults in Virtual Bridged Local Networks. DDCFM is an extension of Connection Fault Management (CFM). As with CFM, DDCFM can be used in networks operated by multiple independent organizations, each with restricted management access to the equipment of other organizations.
There are two broad types of faults in Bridged Networks that affect only frames or sequence of frames carrying certain data, addresses, or combinations of them. Simple data-dependent faults are those that result in the repetitive loss of each of frames carrying particular data, independent of any other frames. Data-dependent faults are usually the result of simple misconfiguration or of a failure to appreciate the consequences of a configuration option (for example, installing protocol specific filters). Data-driven faults are more complex and arise when the presence (or absence) of some data frames causes or contributes to the loss of other frames. While the services supported by bridged networks are notionally data-independent, the use of data-driven techniques enables enhanced service delivery. Examples include (1) multicast frame filtering and consequent bandwidth saving is facilitated by IGMP snooping; (2) stateful firewalls are used to protect users connected to managed services; and (3) efficient allocation of frames to the individual links of an aggregation (802.3ad Link Aggregation) is often based on spotting conversations by looking at frame data.
The major task of detecting data-dependent and data-driven faults (DDFs) is to discover where the DDFs actually occur. Once the DDFs are isolated to a small enough network segment, such as a bridge port or a Maintenance Point (MP), the next step of detecting why or how those data patterns or sequences actually cause the fault at this location becomes much easier. The basic procedure to isolate a DDF is to divide the network into multiple segments and determine whether the suspected data frames can traverse through each segment as expected. When a network segment is identified as being responsible for the problem, the segment is further divided into smaller segments until a bridge, a port, or a CFM Maintenance Point is identified as responsible for not passing through the service instances or the suspected data frames with expected quality. The DDF may not be apparent in the absence of live traffic (that is, when test data are used). Therefore, diagnosis must be carried out while the network is actually running, and the diagnostic tools themselves must not introduce further data-dependent faults.
DDCFM is a tool enabling operators to detect, isolate, and verify data-dependent and data-driven faults. There are two types of DDE testing: Forward Path Testing (FPT) and Return Path Testing (RPT).
FIG. 1 is a simplified block diagram of an existing mechanism for performing Forward Path Testing (FPT) for data-dependent and data-driven faults. The goal of FPT is to determine whether a specified traffic flow (for example, frames associated with a service instance or selected data frames with the same Destination Address, and the like) can reach a particular location such as a bridge pork or a Maintenance Point without dropping packets or developing other errors. In FIG. 1, an identified traffic flow is transmitted from a source node (A) 11 to a destination node (B) 12. FPT is achieved by reflecting (or turning around) the identified traffic flow at a reflection point 13 to a specific target location (T) 14, which could be a bridge, a test equipment, or the source node A. The reflected frames are encapsulated with a CFM header. The target location verifies the reflected data frames. There are many ways for the target location to verify the reflected data frames. For example, the target location may compare the reflected frames with the original ones to determine whether there are any errors. Alternatively, the target location may run a proxy application to simulate the handshakes as if those packets actually reach their original destinations.
FIG. 2 is a simplified block diagram of an existing mechanism for performing Return Path Testing (RPT) for data-dependent and data-driven faults. The goal of RPT is to determine whether a traffic flow can be sent without error from a specific point within a network to a station or stations specified by the destination address (DA) associated with the frames of the Flow-Under-Test. In FIG. 2, RPT is performed by encapsulating each frame of the Flow-Under-Test with a CFM header at an Originating station 21. The destination of the encapsulated flow is the starting point 22 of Return Path Testing. At the RPT starting point, the DDCFM encapsulated frames are decapsulated and forwarded to the station or stations specified by the DA field in the frames of the Flow-Under-Test (for example, node A 23).
FIG. 3 is a functional block diagram of an existing Maintenance association End Point (MEP), as illustrated and described in the IEEE 802.1ag/D8.0 document, “Draft Standard for Local and Metropolitan Area Networks—Virtual Bridged Local Area Networks—Amendment 05: Connectivity Fault Management”, February 2007 (hereafter “IEEE 802.1ag/D8”).
FIG. 4 is a functional block diagram of an existing Maintenance domain Intermediate Point (MIP) Half Function, as also illustrated and described in IEEE 802.1ag/D8.0.